home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13453 < prev    next >
Encoding:
Text File  |  1996-08-05  |  5.9 KB  |  154 lines
  1. Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  2. Path: lego.wes.mot.com!mothost!schbbs!news
  3. From: shang@corp.mot.com (David L. Shang)
  4. Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
  5. Reply-To: shang@corp.mot.com
  6. Organization: MOTOROLA 
  7. Date: Mon, 25 Mar 1996 16:00:11 GMT
  8. Message-ID: <1996Mar25.160011.13921@schbbs.mot.com>
  9. References: <Doq3sv.MzA@research.att.com>
  10. Sender: news@schbbs.mot.com (SCHBBS News Account)
  11. Nntp-Posting-Host: 129.188.128.126
  12.  
  13. In article <Doq3sv.MzA@research.att.com> bs@research.att.com (Bjarne Stroustrup  
  14. <9758-26353> 0112760) writes:
  15. > billf@jovial.com (Bill Foote) writes
  16. > 
  17. > 
  18. >  > > quote explaining why C++ (and Java) uses the termination model
  19. >  > > of exception handling
  20. >  > 
  21. >  > A cynic might conclude something more along these lines:  "It would be 
  22. >  > hard to implement resumable exceptions in C++, so they decided to punt."
  23. > 
  24. > and that "cynic" would be wrong, guilty of not having done his homework,
  25. > and guilty of making unkind conjectures without basis in facts.
  26. >
  27.  
  28. But I don't see what's wrong with the cynic. It is true that to
  29. implement resumable exceptions in C++ is very hard. It is also
  30. true that resumable exception is useful, see below.
  31.   
  32. > Here, I'd like to quote a key section:
  33. > 
  34. >     Then, at the Palo Alto meeting in November 1991, we heard a
  35. >     brilliant summary of the arguments for termination semantics
  36. >     backed with both personal experience and data from Jim Mitchell
  37. >     (from Sun, formerly from Xerox PARC). Jim had used exception
  38. >     handling in half a dozen languages over a period of 20 years
  39. >     and was an early proponent of resumption semantics as one of
  40. >     the main designers and implementers of Xerox's Cedar/Mesa system.
  41. >     His message was
  42. > 
  43. >         ``termination is preferred over resumption; this is
  44. >         not a matter of opinion but a matter of years of
  45. >         experience. Resumption is seductive, but not valid.''
  46. > 
  47. >     He backed this statement with experience from several operating
  48. >     systems. The key example was Cedar/Mesa: It was written by people
  49. >     who liked and used resumption, but after ten years of use, there
  50. >     was only one use of resumption left in the half million line
  51. >     system -- and that was a context inquiry. Because resumption
  52. >     wasn't actually necessary for such a context inquiry, they removed
  53. >     it and found a significant speed increase in that part of the
  54. >     system. In each and every case where resumption had been used
  55. >     it had -- over the ten years -- become a problem and a more
  56. >     appropriate design had replaced it. Basically, every use of
  57. >     resumption had represented a failure to keep separate levels
  58. >     of abstraction disjoint
  59. > 
  60. >     Mary Fontana presented similar data from the TI Explorer system
  61. >     where resumption was found to be used for debugging only, Aron
  62. >      Insinga presented evidence of the very limited and nonessential
  63. >     use of resumption in DEC's VMS, and Kim Knuttilla related exactly
  64. >     the same story as Jim Mitchell for two large and long-lived
  65. >     projects inside IBM. To this we added a strong opinion in favor
  66. >      of termination based on experience at L.M.Ericsson relayed to
  67. >     us by Dag Bruck.
  68. > 
  69. >     Thus, the C++ committee endorsed termination semantics.
  70. > 
  71.  
  72. The key point is: WHAT IS AN EXCEPTION?
  73.  
  74. The definition:
  75.  
  76. >    "Exception handling is intended to allow code that has encountered 
  77. >a condition it cannot cope with to return to some other code that 
  78. >directly or indirectly invoked it. There is no way for an exception 
  79. >handler to request the thread of control to resume from the throw point. 
  80. >In other words, "throw" implements the termination model of exception 
  81. >handling."     -ARM, Ellis & Stroustrup, page 354
  82. >
  83.  
  84. narrows exceptions to error conditions only. If it is this case
  85. termination would be sufficient, and resumptions would be useless.
  86.  
  87. But an exception is not necessarily an error. Sometimes it is an
  88. condition that requires some extraordinary computation, a condition
  89. that is not supposed for a regular case, for example, to open a
  90. configuration file in an application directory and the file is not
  91. found. This condition requires a further processing, e.g. to look up
  92. the file in system directory. This is a quite common case in every
  93. system design. More examples:
  94.  
  95.       * the font does not exist and a query to the user is required to
  96.     get the substituting font;
  97.       * the input is in the wrong type and an input retry is required;
  98.       * the file is not associated with a default handler, would you
  99.     like to associate one and let me try to re-open the file?
  100.       * the format is not understood, would you suggest me a
  101.     converter?
  102.       * the embedded object is re-located, would give me the directory
  103.     to the new place?
  104.  
  105. These conditions are not errors but only require some extraordinary work.
  106. Similar examples were also given by Bill Foote in his previous post.
  107. It is not hard for people to figure out more examples that requires the
  108. following struture:
  109.  
  110.  result    = try do_something()
  111.       {
  112.         when condition1: some_extraordinary_work1; retry;
  113.         when condition2: some_extraordinary_work2; retry;
  114.         when condition3: some_extraordinary_work3; retry;
  115.         when condition4: return null;
  116.       }
  117.  
  118. is certainly better than:
  119.  
  120.     result = do_something();
  121.     exceptional_condition = check_error_message();
  122.     while (exceptional_condition)
  123.     {
  124.         if (exceptional_condition==condition4)
  125.         {
  126.         result = null;
  127.         break;
  128.         }
  129.         switch (exceptional_condition)
  130.         {
  131.         case condition1:
  132.             some_extraordinary_work1;
  133.             do_something();
  134.             break;
  135.         case condition2:
  136.             some_extraordinary_work2;
  137.             do_something();
  138.             break;
  139.         case condition3:
  140.             some_extraordinary_work3;
  141.             do_something();
  142.             break;
  143.         }
  144.     }
  145.  
  146. Oh, well! It takes me ten time longer to figure out the second piece of
  147. code and I am still not sure whether this code is correct or not. After
  148. a second look, yes, there are errors! "check_error_message()" should also
  149. be called in the loop to get the new exceptional condition after a retry.
  150.  
  151. David Shang
  152.  
  153.  
  154.